Action scripts (also known as “media action scripts” or “media action graphics”) are typically string-based, tag-based, and/or bytecode-based interpretable files with variable-length operands providing corresponding data, which are used to provide rendering of many different types of media (hereinafter “multimedia”) for visual display, audio playback, and other sensory feedback, such as the various scripting languages utilized for rendering web pages, graphics, animation, gaming and other multimedia content, which may be dynamic or static, including without limitation graphics, animation (e.g., as a dynamic graphical image changing over time), text, audio, video, pictures, photographs, sprites, and other images for display. Representative action scripts include Adobe Flash®, Sun Microsystems Javascript® and JavaFX®, Microsoft Silverlight®, ECMA Script, Scalable Vector Graphics (“SVG”), Vector Markup Language (“VML”), Precision Graphics Markup Language, “PGML”), Action Graphics, Adobe Flash® Lite™, Ruby, Perl, and Python, for example. In the prior art, such an action script is typically interpreted and subsequently executed using multiple layers of software (typically referred to as a software stack (or stack machine) or a protocol stack), operating as application layers and using an operation system within a general purpose computer, e.g., as part of or embedded within another application or program, such as by a media player or virtual machine operating as a first application layer or plug-in within a second application layer such as a web browser, using an operating system such as Windows® XP or Apple Leopard®.
All of these various scripting languages are “string” or bytecode-based, as stings are known in the art as a sequence of characters which have been ASCII-encoded (American Standard Code for Information Interchange (“ASCII”)), using string-based “tags” or bytecode (or their equivalent) with variable-length operands to indicate a desired graphical image or other type of image media (e.g., graphics (static and dynamic), animation (as dynamic graphics), gaming, text, sprites, etc.) that should be rendered, using specific or dedicated software for each type of action script, in a first application layer typically operating in conjunction with a second application layer. In addition, all of these various scripting languages are “interpreted” by another application, such that unlike most computer applications, they are not compiled to machine code, and generally are either string-based or are semi-compiled to bytecode, and do not comprise directly executable code (assembly code or machine code) which runs natively on a given microprocessor architecture. In addition, the graphical objects specified by such media action scripts are not specified pixel-by-pixel in a bitmapped or in a matrix form (in compressed or uncompressed forms), in contrast to the data comprising photographs (e.g., Joint Photographic Experts Group (“JPEG” or “jpeg”) files) or video, such as an MPEG (Moving Picture Experts Group (“MPEG” or “mpeg”) files) or an H.264 standard video macroblock having defined information for each pixel (which also may be compressed), followed by blocks indicating changed information, followed by another macroblock, and so on. For example, representative action scripts are currently interpreted using a Flash Media Player, Gnash, Mplayer, a Java virtual machine or another form of virtual machine or player as part of web browser operation, such as Internet Explorer, Safari, Google Chrome, Opera, Mozilla Firefox, Netscape Navigator, OmniWeb, Flock, Camino, SeaMonkey, Epiphany, etc., and further may include additional software calls for graphics primitives from graphics libraries, such as Cairo. Such an action script file is typically provided as part of a larger data file, such as a web page specified using a hypertext markup language (“HTML”) or extensible markup language (“XML”), or more generally as part of a hypertext transfer protocol (“HTTP”) data file. (It should also be noted that a “time” element is inherent in these scripting languages and file types, insofar as images which are perceived to be dynamic by the user, such as sprites and video, are comprised of a succession of static images (i.e., static during any given time interval (or frame), with the time intervals sufficiently short that the image succession is perceived as change and movement, for example).
In prior art systems, such graphical rendering from an action script file provided as part of an HTML or XML file, for example, is a very demanding application, extremely computationally intensive, requiring execution of extensive software protocol stacks and application program interface (“API”) calls, requiring significant microprocessor capability, and typically requiring at least one additional, separate graphics processor provided in a comparatively powerful computing system. For example, FIG. 1 is a diagram illustrating a representative, prior art software or protocol stack 10 for action script processing, and has been derived from published diagrams (which may be found at http://i.technet.microsoft.com/Cc749980.xwr_d16(en-us,TechNet.10).gif and http://www.elvenware.com/charlie/DirectX/DDrawArch.bmp). In this representative protocol stack 10, each higher layer performs one or more software calls to the next lower software layer to process an HTTP (or HTML or XML) data file 5, any given layer may be recursive, and any lower layer may also call a higher level construct and return to a higher software level, and includes:                (1) Action script player or virtual machine application 15 in the application layer 30;        (2) web browser application 20 (also in the application layer 30);        (3) API calls 25 to another program (e.g., direct draw) from the web browser or action script player, such as GTK or X11 (also in the application layer 30);        (4) calls to a graphics device interface 35 in the operating system layer 40, such as calls to Open GL; and        (5) calls to a display device interface 45 (also in the operating system layer 40), which further includes:                    (5a) calls to a display driver 50;            (5b) calls to an input/output (I/O) manager 55; and            (5c) calls to a video port 60 and/or multimedia driver 65;which then finally provide machine-specific calls to hardware, illustrated as video card 70 (in hardware layer 75), for performing computation that actually results in pixel information for rendering the graphical image or object, which is then output to a display (155) (also in hardware layer 75). Processing of this software (or protocol) stack 10, with many intervening software layers before a hardware instruction is reached which performs the computations, is extraordinarily computationally intensive.                        
These demanding computational requirements have effectively eliminated the ability for such graphical rendering in most handheld devices or in comparatively less expensive computers which do not have significant graphics engines and/or sophisticated central processing units (CPUs). Because such prior art handheld and other devices do not have this significant processing capability, web-based graphics for such devices may not be provided at all, or are typically provided in modified, stripped-down or otherwise reduced versions, such as Flash Lite™, allowing only a subset of available web pages to be accessed, or result in such slow performance so as to render the device effectively unusable or inoperative. As another prior art alternative, HTTP requests from such devices are redirected to another, related web site which does not require rendering of such computationally-intensive action scripts, or such action scripts are simply not implemented altogether. In addition, these significant processing requirements have effectively required comparatively expensive computers, which are unavailable to many consumers in many markets throughout the world.
Various prior art attempts to accelerate processing of web pages have not addressed these demanding computational requirements and have not provided any mechanism to accelerate processing of action scripts. For example, Lemoine U.S. Patent Application Publication No. US 2006/0277459, published Dec. 7, 2006, discloses a method of accelerating processing of XML pages through XML caching, and more specifically by speculatively and asynchronously processing portions of the web page in advance, so that those portions are immediately available to the web browser if needed. While display to a user of an XML page may be accelerated, actual processing requirements have been increased using this method, as potentially unused portions of the web page have also been processed unnecessarily. In addition, no acceleration of action scripts or vector graphics has been provided or otherwise disclosed.
Similarly, Graffagnino et al. U.S. Patent Application Publication No. US 2008/0120626, published May 22, 2008, discloses a hardware accelerated web engine which caches parts of graphical images, and more specifically renders graphical images in parts and stores those parts separately, so that in the event those portions of the web page have not changed in a succeeding web page, these rendered parts may be re-used without re-rendering. While successive frames of a web page may be accelerated in this prior art method by re-using previously rendered and unchanged portions of images, the actual (or initial) rendering of the images themselves has not been accelerated in any way or form. In addition, this prior art method cannot provide any processing acceleration of graphical images which change from frame to frame, such as to indicate movement or rotation, which do not re-use previously rendered components.
These prior art acceleration methods have not addressed, and have not disclosed, any apparatus, method or system to accelerate the actual processing of an action script, such as Flash®, Silverlight®, JavaFX® or Javascript®, or even more generally, acceleration of the processing of vector graphics or SVG, to render a graphical image (or object). These prior art acceleration methods have not addressed, and have not disclosed, any apparatus, method or system to bypass all or any portions of the processing of the software protocol stack (10) currently utilized to process such an action script or vector graphics to render a graphical image (or object). As of this date, this state of affairs has remained for over eighteen years.
Accordingly, a need remains for an apparatus, method and system which accelerates the processing of an action script and related vector graphics and multimedia components which may be provided as part of a web page, a game, animation, or other types of data files. Such a hardware accelerator should eliminate the necessity of the complicated and inefficient prior art protocol stack, along with the often multiple traversals of the protocol stack, for providing graphics rendering. For example, an exemplary hardware accelerator should provide for one hardware layer between the browser 20 and display 155 of FIG. 1. Such a hardware accelerator should be capable of implementation in a mobile device, a handheld device, a server, a television, an audio-visual (AV) receiver, a projector, telematics, or other devices, for example, without requiring both the significant microprocessor capability and/or the additional graphics processor of the prior art. Such an accelerator should enable complete display of a graphical image without redirection to another, modified web site. Such an accelerator should also be readily updatable or reconfigurable to accommodate new, currently unknown types of action scripts, graphics or multimedia standards. Lastly, such an accelerator should be compatible with and transparent to existing processors and devices, and directly usable with such devices without requiring retrofitting or modification of such processors.